home *** CD-ROM | disk | FTP | other *** search
/ ETO Development Tools 1 / ETO Development Tools 1.iso / Essentials / C++ AppleLink Messages / CPlus.Dev$ 6⁄8⁄90 / 0139-Re c++ & the heap-Jun90 < prev    next >
Encoding:
Text File  |  1990-06-08  |  3.1 KB  |  75 lines  |  [TEXT/GEOL]
  1. Item    5861365                         4-June-90        11:04PDT
  2.  
  3. From:   ISAACSON                        Isaacson, Trygve
  4.  
  5. To:     D4202                           HLH Assoc, Seth Haberman,PRT
  6.         CPLUS.DEV$                      C++ Interest List--Developers
  7.         CPLUS.APPLE$                    C++ Interest List--Apple Employees
  8.  
  9. Sub:    Re> c++ & the heap
  10.  
  11. Scot,
  12.  
  13. C++ doesn't really change the face of the Mac.  You can still use
  14. non-relocatable memory (resulting in heap fragmentation, etc., just like
  15. in the DOS world), or you can use relocatable memory (and worry about memory
  16. moving underneath your dereferenced handles).
  17.  
  18. The Good News:  if you just use the 'new' operator to create pointer-based
  19. objects, you don't have to worry about the objects moving.  This is because
  20. 'operator new' uses 'malloc' from the standard C library, and malloc maintains
  21. its own list of blocks which are allocated with 'NewPtr'.
  22.  
  23. The Bad News:  you <probably> don't want to do this!  Malloc is not a very
  24. friendly companion to the Memory Manager.  Your heap may become fragmented and
  25. you will find that malloc never frees blocks under 2K in size (it assumes it is
  26. the only one doing the allocation, so it just keeps the free blocks around for
  27. later use).  You can live with this if you don't use the Memory Manager, but if
  28. you use the Toolbox at all, you will at least indirectly be using the Memory
  29. Manager, and it may cause you brainaches.
  30.  
  31. The Solution:  derive your objects from a class that doesn't use malloc for
  32. allocation.  Oh look, here's one now (built-in to MPW C++):  'HandleObject'.
  33. Of course, you will have to worry about HandleObjects moving, but you can put a
  34. Lock() and Unlock() method in your own superclass you descend from HandleObject
  35. (see below) and use care to ensure you lock objects at the right times (all the
  36. traditional memory-moving gotcha situations apply), or I suppose you could make
  37. the convention that you MoveHHI() and HLock() your objects in their init method
  38. (but that would be cheating...?).
  39.  
  40. I suggest reading Andy Shebanow's article in the April issue of Develop if you
  41. want to know about malloc and the Mac.  He gives an example class 'PtrObject'
  42. which doesn't use malloc but isn't relocatable like HandleObject.  In case
  43. you're interested, here's my ulitimate superclass from which all my objects
  44. descend (the lock and unlock methods use a counter so I can nest my locks and
  45. unlocks without getting burned by nested HLock and HUnlock):
  46.  
  47. class TOrionObject : public HandleObject
  48.   {
  49.   public:
  50.  
  51.   virtual void  IOrionObject();
  52.   virtual void  Free();
  53.   virtual void  Fields(TInspector *inspector);
  54.  
  55.   void Lock()   { if (fLockCount++ == 0) HLock((Handle) this); }
  56.   void Unlock() { if (--fLockCount == 0) HUnlock((Handle) this); }
  57.  
  58.   protected:
  59.  
  60.   OSType  fID; // each class inits this to its identifier
  61.  
  62.   private:
  63.  
  64.   lhex    fLockCount;
  65.   };
  66.  
  67. If you're using MacApp (it doesn't sound like you are), you're probably better
  68. off subclassing from TObject (which is handle-based) since it gives you some
  69. more stuff for free.
  70.  
  71. Trygve Isaacson
  72. Orion Network Systems, Inc.
  73. Link: ISAACSON
  74.  
  75.